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Abstract 

Many  novel  features  of  Ada  (e.g.,  packages,  generics,  tasking,  and  exception  handling) 
were  Included  In  the  language  to  Improve  readability,  aid  modification,  or  encourage 
reusability.  Since  they  have  not  been  available  In  other  widely  used  languages,  packages 
present  programmers  with  a  fairly  formidable  learning  task.  We  studied  four  first-time 
Ada  programmers  as  they  developed  a  ground-support  satellite  system.  Metrics  are 
presented  which  characterize  their  use  of  Ada  packages.  Indicating  where  program  struc¬ 
ture  may  make  changes  difficult,  and  suggesting  how  the  structure  may  be  Improved. 
Our  findings  suggest  that  a  good  background  In  the  software  engineering  practices  sup¬ 
ported  by  Ada  Is  necessary  to  learn  to  use  the  features  of  the  language  —  simply  teach¬ 
ing  professional  programmers  Ada  Is  not  enough.  . 


1.  Introduction 

When  programmers  begin  to  learn  a  new  language,  they  often  start  by  using  those 
features  of  the  language  that  appeared  In  other  languages  they  already  know.  For 
example,  a  study  of  102,307  statements  In  PL/I  programs  turned  up  7385  DO  state¬ 
ments,  but  only  11  DO  WHILE  statements  (Elshoff  76].  Elshoff  concluded: 

“The  most  basic,  general  form  of  the  DO  statement  is  not  used.  The  fact  that  the  pro¬ 
grammers  do  not  know  of  its  existence  is  a  primary  reason.” 

Error  messages  associated  with  novel  constructs  often  provoke  Inappropriate  responses. 
In  a  language  In  which  programmers  had  to  explicitly  request  the  right  to  access 
Identifiers  declared  In  outer  units  of  scope  Instead  of  Inheriting  them  automatically 
[Gannon  and  Horning  75],  programmers  responded  to  messages  about  lack  of  access  to 
an  Identifier  by  making  all  possible  Identifiers  visible. 

2.  Modules 

Modules  allow  programmers  to  group  related  data  and/or  procedures  and  to  limit 
the  amount  of  Information  that  Is  accessible  to  the  rest  of  the  program  [Parnas  71). 
Splitting  a  program  Into  modules  should  localize  the  effects  of  program  changes  to 
correct  errors  or  to  Improve  the  Implementation  (l.e.,  making  It  more  robust  or  more 
efficient).  In  addition,  since  modules  are  usually  self-contained,  they  can  be  reused  from 
project  to  project.  The  designers  of  Ada  [Ichblah  et  al.  79]  recognized  three  major  uses 
for  modules: 

(1)  A  named  collection  of  declarations  that  makes  a  group  of  types  and  variables  avail¬ 
able  much  like  a  FORTRAN  common  block. 

(2)  A  group  of  related  subprograms  that  provides  a  library  facility. 

(3)  An  encapsulated  data  type  that  provides  the  names  of  the  type  and  Its  operations, 
but  hides  the  details  of  f  ue  representation  of  objects  of  the  type  and  of  the  Imple¬ 
mentation  of  the  type's  operations. 

While  the  first  two  uses  are  familiar  to  many  programmers,  the  third  use  Is  not  sup¬ 
ported  by  many  commonly-used  programming  languages.  Strong  syntactic  clues  are 
available  to  help  programmers  decide  what  objects  comprise  the  first  two  kinds  of 
modules  (e.g.,  all  types  and  constants,  a  collection  of  global  variables,  or  a  set  of  utility 
routines),  but  fewer  hints  are  available  to  aid  In  grouping  objects  In  problem-oriented 
terms  [Ledgard  85]. 

One  of  the  lessons  of  structured  programming  Is  that  simply  providing  users  with 
“goto-less”  programming  languages  does  not  result  In  structured  programs  being  written. 
Users  need  to  understand  the  Ideas  of  top-down  development  and  stepwise  refinement  to 
produce  structured  programs.  Our  hypothesis  was  that  a  similar  phenomenon  was  likely 
to  occur  with  Ada  packages.  Users  who  were  unfamiliar  with  the  Ideas  of  Information 
hiding  and  data  abstraction  were  unlikely  to  use  Ada  packages  to  write  programs  that 
exhibited  these  properties.  Thus,  the  need  for  training  at  the  professional  level  would 
likely  be  for  software  design  techniques,  not  Just  the  Ada  programming  language. 


3.  Ada  Packages  and  Units 

In  Ada,  modules  are  Implemented  as  packages.  A  package  consists  of  two  parts:  a 
specification  and  a  body.  The  specification,  which  contains  declarations.  Is  further 
divided  Into  visible  and  private  parts.  Identifiers  declared  In  the  visible  part  can  be 
used  by  other  units,  while  those  declared  In  the  private  part  can  only  be  used  In  the 
package  body.  For  example,  the  following  package  specification  exports  the  name  of  the 
type  Rational  with  operations  /,  +,  etc.  The  representation  of  a  rational  number  by  a 
record  containing  two  Integers  Is  hidden  from  users  In  a  private  part. 

package  Rational  Is  —  specification  part 
--  visible  part 
type  Rational  Is  private; 

function  (X,Y:  Integer)  return  Rational;  —  to  construct  a  rational 
function  (X,Y:  Rational)  return  Rational; 

private 

type  Rational  Is 
record 

Numerator,  Denominator:  Integer; 
end  record; 

end; 

The  package  body  contains  Implementations  of  operations  and  declarations  of  types 
whose  names  appear  In  the  corresponding  specification  part.  Nothing  declared  In  the 
package  body  Is  visible  outside  the  package.  However,  package  bodies  and  specifications 
can  use  Information  from  other  packages’  specifications. 

Packages  are  not  required  to  hide  the  representation  of  data.  The  specification  for 
Rational  numbers  above  could  have  been  declared  as  follows. 

package  Rational  Is  --  specification  part 
—  visible  part 
type  Rational  Is 
record 

Numerator,  Denominator:  Integer; 
end  record; 

function  "/"  (X,Y:  Integer)  return  Rational;  --  to  construct  a  rational 
function  (X,Y:  Rational)  return  Rational; 

end; 

However,  If  the  representation  Is  defined  In  the  visible  part  of  the  specification,  any 
other  units  which  can  see  the  package  can  manipulate  the  representation  of  the  data 
(e.g.,  may  access  the  Numerator  or  Denominator  field  of  any  Rational  object).  Changes 
In  the  representation,  therefore,  might  have  a  tremendous  effect  on  those  units. 


Encapsulating  data  types  In  packages  allows  the  definition  of  objects  and  their 
associated  operations.  Hiding  the  representation  of  the  data  either  In  the  private  part  of 
the  package  specification  or  In  the  package  body  limits  the  effects  of  changes  In  the 
representation.  If  It  Is  In  the  private  part,  changing  the  representation  can  necessitate 
recompilation  of  units  using  the  package.  If  It  Is  In  the  body,  changes  will  not  force 
recompilation,  but  the  Implementation  may  be  more  difficult. 

Ada  programs  are  collections  of  compilation  units:  pre-defined  units,  package 
specifications,  and  others  (l.e.,  subprogram,  package,  and  task  bodies).  Where  a  package 
Is  defined  Is  another  Important  decision.  A  package  might  be  generally  available  to  any 
other  unit  In  the  environment.  It  may  be  defined  In  a  library  restricted  to  a  project  or 
group  which  will  limit  the  package  availability  to  a  subset  of  units.  The  author  of  a 
package  also  has  the  option  of  defining  packages  within  other  units  limiting  the  scope  to 
teh  defining  unit.  By  choosing  an  appropriate  location  for  a  package’s  definition,  the 
package’s  author  can  limit  the  scope  of  possible  changes. 

The  final  aspect  of  packages  examined  In  this  paper  concerns  the  visibility  of  pack¬ 
ages  within  other  units.  A  package  Is  visible  In  a  unit  If  one  of  the  following  occurs. 
First,  the  package  Is  named  In  a  with  clause  at  the  beginning  of  the  unit.  Second,  the 
package  Is  visible  In  the  unit’s  parent  unit.  Items  declared  In  the  package  can  be  made 
directly  visible  with  a  use  clause  In  the  same  manner.  However,  In  this  paper,  we  con¬ 
centrate  on  general  visibility  as  opposed  to  direct  visibility.  Reducing  package  visibility 
should  lower  the  vocabulary  of  the  unit.  Studies  [Elshoff  76]  show  that  this  might 
Increase  the  comprehensibility  of  the  unit.  In  addition.  It  would  lower  the  number  of 
possible  bindings  [Baslll  and  Turner  76]  between  the  unit  and  the  package. 

4.  Package  Metrics 

Metrics  based  on  packages  can  be  used  to  characterize  the  structure  of  a  program. 
They  can  also  Indicate  where  problems  may  occur  If  the  representations  of  data  objects 
or  the  Implementations  of  operations  change.  Most  Importantly,  they  provide  feedback 
to  programmers  about  the  effects  of  their  definition  and  use  of  packages. 

There  are  many  simple  characterizing  metrics  that  provide  a  sketch  of  the  system: 
the  number  of  packages  declared,  and  the  number  of  generic  packages  and  the  number 
of  times  each  Is  Instantiated.  In  addition  to  these  simple  metrics,  two  more  elaborate 
metrics  are  discussed  below. 

4.1.  Package  Vbibility 

One  means  of  measuring  packages  Is  to  look  at  their  visibility  to  other  units  In  the 
system.  We  examine  two  versions  of  a  system  -  the  current  one  and  one  where  the  with 
clauses  may  have  been  moved  to  lower  the  visibility. 

4.1.1.  Definitions 

Each  package  has  the  following  visibility  measures: 

(1)  used:  number  of  units  where  Information  from  the  package  Is  accessed  or  changed. 


(2)  current:  number  of  units  where  the  package  Is  currently  visible. 

(3)  available:  number  of  units  where  the  package  could  be  made  visible  by  adding  a 
with  clause,  given  the  current  unit  structure. 

(4)  proposed:  number  of  units  where  the  package  Is  visible  given  the  current  unit  struc¬ 
ture  and  the  with  clauses  In  their  lowest  possible  positions. 

Only  those  units  that  are  part  of  the  current  system  are  Included  In  our  measures.  In 
addition,  package  bodies  and  their  subunits  are  not  Included  In  the  measures  for  that 
package  because  they  are  part  of  Its  Implementation.  These  values  can  be  computed 
during  the  design  of  a  system  or  after  the  system  has  been  completed. 

4.1.2.  Examples 

Figures  l  and  2  Illustrate  three  views  of  a  small  system  containing  the  following 
components:  package  P  defining  a  procedure  X;  and  procedure  A  defining  subunits  B,  C, 
and  D.  In  Figure  1,  there  Is  a  with  clause  for  P  In  A;  therefore,  P  Is  currently  visible  In 
four  units.  (X  Is  not  Included  In  these  measures  because  It  Is  a  subunit  of  P.)  However, 
P.X  Is  only  used  In  two  units,  B  and  D.  In  Figure  2,  we  propose  moving  the  with  clause 
from  A  to  B  and  D,  limiting  the  visibility  of  P  to  three  units.  For  a  system  In  which  C 
Is  a  subunit  of  B,  that  Is  the  lowest  location  for  the  with  clauses. 

4.1.3.  Visibility  Ratios 

Three  Interesting  visibility  ratios  for  the  systems  In  Figures  1  and  2  are  given  In 
Table  1. 


Table  l:  Ratios  of  Visibility  Vectors 


Full  Name 

Notation 

(1) 

(2) 

used/avallable 

UA(P) 

0,5 

0.5 

used/proposed 

UP(P) 

0.7 

1.0 

proposed /current 

PC(P) 

0.8 

1.0 

Each  of  these  ratios  has  an  upper  bound  of  one  and  a  lower  bound  of  zero.  The 
ratio  of  units  In  which  a  package  Is  accessed  to  those  In  which  It  could  be  made  avail¬ 
able  (UA)  Is  a  measure  of  the  perceived  generality  of  the  package.  If  UA(P)  Is  high, 
package  P  Is  only  available  where  necessary;  therefore,  the  designers  may  have  made  It 
for  a  specific  purpose.  However,  If  UA(P)  Is  low  (l.e.,  P  Is  available  much  more  widely 
than  Is  necessary),  the  designers  may  believe  that  the  package  Is  generally  useful. 

The  ratio  of  the  number  of  units  In  which  the  package  Is  accessed  to  those  where  It 
must  be  made  available  (UP)  measures  excess  visibility  for  the  current  system  structure. 
For  example.  In  Figure  2,  P's  visibility  In  C  cannot  be  eliminated  as  long  as  C  Is  a 
subunit  of  B.  UP  can  be  used  to  compare  different  system  structures  In  which  excess 
visibility  has  been  removed. 

Finally,  the  ratio  of  the  number  of  units  In  which  a  package  must  be  visible  to 
those  In  which  It  Is  visible  measures  the  design  decision  to  minimize  visibility.  If  PC(P) 
Is  low,  P  Is  considered  as  global  data  or  operations  even  If  a  less  visible  arrangement  Is 
available.  If  PC(P)  Is  high,  a  decision  might  have  been  made  to  limit  the  visibility  of  P. 


Had  the  design  goal  been  minimizing  the  visibility  of  packages  used,  the  second 
subunit  structure  would  be  better.  The  ratios  should  be  used  to  Indicate  which  pack¬ 
ages  should  be  examined  more  closely,  not  to  replace  the  need  to  understand  why  design 
decisions  have  been  made. 

4.2.  Component  Accesses 

When  selection  operations  are  applied  to  composite  objects  outside  package  bodies, 
details  of  data  representation  are  spread  throughout  the  program.  Distributing 
representation  Information  rather  than  centralizing  It  In  private  parts  of  package 
specifications  makes  programs  more  difficult  to  change.  If  the  type  of  the  composite 
object  Is  not  defined  locally,  changes  In  representation  to  enhance  program  capability  or 
efficiency  could  Involve  many  statements  In  many  compilation  units. 

For  example,  consider  the  Ada  fragment  below  containing  the  visible  type  T2  hav¬ 
ing  two  array  components  (A  and  B)  with  identical  numbers  of  elements  with  the  same 
type  (T). 

—  original  representation 
N:  constant  Integer  :=  ...; 
type  Tl  Is  array  (1..N)  of  T; 
type  T2  Is 
record 
•••♦ 

A:  Tl; 

B:  Tl; 

•  ••♦ 

end  record; 

If  we  Introduced  a  new  type,  NewType,  a  record  of  two  elements  of  type  T,  that  permit¬ 
ted  the  two  array  components  of  the  previous  example  to  be  combined  Into  a  single 
component  (C)  In  T2: 
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--  new  representation 
N:  constant  Integer  := 
type  NewType  Is 
record 
A:  T; 

B:  T; 

end  record: 

type  Tl  Is  array  (1..N)  of  NewType; 
type  T2  Is 
record 


end  record; 

then  all  references  to  the  A  and  B  components  of  type  T2  variables  (e.g.,  V)  would  have 
to  be  changed. 

“  original  representation  —  new  representation 
V.A(...)  V.C(...).A 

V.B(...)  V.C(...).B 

The  following  measures  view  component  accesses  from  the  user’s  perspective.  The 
ratio  of  component  accesses  to  objects  with  non-locally  defined  data  types  to  lines  of 
text  can  be  used  to  measure  the  code’s  resistance  to  changes.  The  ratio  of  component 
accesses  to  objects  with  non-package  defined  data  types  to  lines  of  text  can  be  used  as 
an  Indication  that  more  data  might  be  packaged.  As  In  the  visibility  measures,  subunits 
of  a  package  are  considered  part  of  the  package;  therefore,  any  accesses  In  them  to  the 
enclosing  package  are  considered  local. 

Another  view  of  component  accesses  is  from  the  package’s  perspective.  If  com¬ 
ponents  of  a  package’s  objects  or  types  are  accessed  frequently  or  In  many  other  units, 
changes  to  the  package  may  affect  all  of  those  units.  If  the  representation  Is  available 
but  never  or  rarely  used,  changing  It  might  be  easier  although  encapsulation  may  not  be 
as  necessary.  Measures  of  Interest  here  are  the  number  of  component  accesses  made  to 
objects  or  types  defined  by  the  package  and  the  number  of  units  In  which  those  accesses 
occur. 

5.  A  Case  Study 

The  visibility  and  component  access  metrics  described  In  the  previous  section  have 
been  applied  to  a  subset  of  an  existing  ground-support  system  for  a  satellite,  which  was 
redesigned  and  Implemented  In  Ada  (Baslll  et  al.  82),  (Baslll  et  al.  84],  (Baslll  et  al.  85). 
With  the  help  of  the  original  designers  of  the  system,  requirements  were  developed  for  a 
subset  system  that  Included  an  Interactive  operator  Interface,  graphic  output  routines, 
and  concurrent  telemetry  monitoring. 


This  was  an  early  Ada  development  to  examine  the  effect  of  using  Ada  In  an  Indus¬ 
trial  environment.  The  four  programmers  had  diverse  backgrounds.  The  lead  program¬ 
mer  had  substantial  Industrial  experience  In  the  application  area  and  was  fluent  In  FOR¬ 
TRAN  and  assembler  languages.  The  senior  programmer  had  less  experience  In  the 
application  area,  but  wider  exposure  to  languages  (COBOL,  PL/I,  Lisp,  ALGOL,  and 
SNOBOL  as  well  as  FORTRAN  and  assembler).  The  Junior  programmer  was  a  recent 
computer  science  graduate  who  had  no  Industrial  experience.  He  was  familiar  with  Pas¬ 
cal  In  addition  to  all  the  languages  with  which  the  senior  programmer  was  familiar.  The 
programmer/llbrarlan  was  a  novice  programmer  who  had  taken  a  single  course  In  FOR¬ 
TRAN  programming. 

Since  none  of  the  programmers  was  familiar  with  Ada,  a  one-month  training  period 
preceded  the  start  of  the  project.  They  viewed  fifteen  hours  of  videotaped  lectures 
given  by  Ichblah,  Firth,  and  Barnes.  A  six-day  In-house  course  by  a  consultant  was 
spread  over  a  period  of  weeks  to  allow  team  members  to  complete  assignments,  the  last 
of  which  was  a  500-llne  team  project.  Another  half-day  was  spent  reviewing  the  pro¬ 
gramming  practices  they  were  expected  to  use:  design  and  code  walkthroughs  and  struc¬ 
tured  programming.  The  results  from  this  project  suggest  that  this  training  was  not 
sufficient  given  the  team's  background.  (Baslll  et  al.  85] 

The  bulk  of  the  development  of  this  system  was  done  with  the  Ada/Ed  Interpreter 
between  February  and  December  1982.  Some  testing  was  done  on  the  ROLM  compiler 
In  the  summer  of  1983.  The  project  was  not  completed  for  a  number  of  reasons.  The 
most  Important  of  those  reasons  was  the  lack  of  production-quality  compilers.  The 
structure  of  the  system  as  well  as  the  package  use  can  be  determined  at  this  stage,  how¬ 
ever. 


5.1.  The  Program 

The  final  program  contained  4375  text  lines  (excluding  comments  and  blank  lines) 
of  Ada.  The  system  contained  11  packages  contained  In  19  units  and  a  main  program 
with  29  subunits.  Some  attempts  were  made  to  decompose  the  functions  of  the  subun¬ 
its;  therefore,  as  many  as  four  nesting  levels  of  subunits  are  used  In  the  system.  Figure 
3  shows  the  structure  of  the  system.  Of  the  eleven  packages  defined,  one's  body  was 
not  written  and  It  was  never  used. 

The  packages  were  of  four  types: 

(1)  2  common  blocks  exporting  only  definitions, 

(2)  3  libraries  exporting  only  functions, 

(3)  4  encapsulated  data  types  exporting  private  type  definitions  and  operations,  and 

(4)  2  data  types  which  exported  the  representation  of  the  type. 

While  these  numbers  seem  to  Indicate  that  the  package  feature  was  used  appropriately, 
closer  examination  refutes  this  conclusion.  Of  the  four  packages  defining  encapsulated 
data  types,  two  were  device  drivers,  another  was  a  mathematical  function,  and  the 
remaining  package  definition  was  neither  completed  nor  used.  Device  drivers  and 
mathematical  libraries  are  common  modules  In  existing  software  systems  --  no  new  fully 
encapsulated  types  were  defined. 
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Five  of  the  eleven  packages  were  generic,  but  each  was  Instantiated  only  once.  The 
generic  parameters  were  primarily  ranges  for  arrays  and  precision  for  real  numbers.  The 
programmers  used  the  standard  sequentlal_lo  package  In  various  Instantiations,  but  they 
only  used  one  Instantiation  for  each  of  the  generic  packages  they  defined.  Of  those  five 
Instantiations,  two  were  In  one  other  package,  and  three  were  In  the  main  program. 
The  programmers  seemed  to  view  packages  as  global  entitles. 

A  more  alarming  discovery  was  that  only  two  of  the  team  members  (those  with 
experience  In  the  widest  variety  of  programming  languages)  defined  any  packages.  The 
other  two  team  members  used  the  conventional  packages  provided  by  the  other  two  pro¬ 
grammers  (l.e.,  the  device  drivers  and  the  mathematical  subroutines)  and  the  standard 
Ada  packages  but  wrote  none  of  their  own.  Even  though  the  requirements  specified 
that  an  antenna  beam-forming  network  had  binary  tree-llke  connectivity  and  a  binary 
tree  package  specification  was  written,  one  programmer  wrote  some  different  Internal 
functions  that  manipulated  a  different  representation  Instead  of  providing  a  package 
body  to  match  the  specification. 

6.  Package  Visibility 

An  examination  of  the  visibility  of  the  packages  within  the  other  units  Indicates 
that  the  system  structure  did  not  minimize  package  visibility.  The  visibility  ratios  for 
the  10  packages  which  were  used  are  given  In  Table  2. 


Table  2:  Package  Visibility  Vectors  and  Ratios 


Package 

Used 

Proposed 

Current 

Available 

UP 

UA 

PC 

1 

0 

13 

30 

mSm 

0.7 

Ka 

0.4 

2 

4 

g 

33 

0.4 

HI 

0.3 

3 

20 

30 

32 

0.7 

0.4 

o.g 

4 

1 

31 

33 

47 

0.0 

0.0 

o.g 

5 

11 

30 

30 

47 

0.4 

0.2 

1.0 

6 

4 

g 

30 

47 

0.4 

0.1 

0.3 

7 

7 

13 

30 

47 

0.5 

0.1 

0.4 

8 

3 

3 

3 

48 

1.0 

0.0 

1.0 

g 

1 

1 

2 

48 

1.0 

0.0 

0.5 

10 

1 

_ 1 _ 

1 

48 

1.0 

0.0 

1.0 

Although  the  main  program  only  used  two  packages,  six  of  the  nine  packages  were 
named  In  both  with  and  use  clauses  there.  Most  of  the  packages  were  viewed  as  global 
data  or  functions  that  were  accessible  everywhere.  This  view  Is  consistent  with  the 
FORTRAN  style  of  programming  most  familiar  to  the  programmers. 

Note  that  the  UA  column  Is  fairly  low  for  all  the  packages  except  package  3.  Pack¬ 
age  3  contains  type  definitions  and  constants  used  throughout  the  system.  The  low 
values  of  UA  suggest  that  some  of  the  packages  could  be  defined  locally  to  groups  of 
units. 


The  system  structure  allows  reasonable  visibility  for  many  of  the  packages,  as  Indi¬ 
cated  In  the  UP  column.  It  Is  possible  to  make  packages  8,  0.  and  10  visible  only  In  the 
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packages  which  use  them.  Packages  1  and  3  do  not  have  an  Inordinate  amount  of  visi¬ 
bility.  However,  packages  2,  1,  5,  6,  and  7  would  probably  benefit  from  a  change  In  the 
subunit  structure  If  It  were  possible. 

Finally,  the  PC  column  demonstrates  the  programmers'  view  of  the  role  of  pack¬ 
ages  In  the  system.  Five  of  the  packages  were  given  the  appropriate  visibility  In  the  ori¬ 
ginal  system;  however,  the  rest  of  the  packages  are  visible  much  more  than  they  need  to 
be.  This  Is  yet  another  example  of  the  programmers'  global  data  approach  to  package 
definition. 

7.  Component  Accesses 

Table  3  summarizes  non-local  component  accesses  for  each  programmer  based  on 
all  modules  written  by  the  programmer.  The  total  number  of  component  accesses,  the 
accesses  to  packaged  data,  and  the  accesses  to  non-packaged  data  are  each  Included. 

These  metrics  show  that  on  average  more  than  one  of  every  ten  lines  (0.11)  of  text 
contained  a  reference  to  a  component  of  an  object  with  an  externally  defined  type. 
Roughly  twice  as  many  references  are  made  to  packaged  data  as  are  made  to  unpack¬ 
aged  data  which  suggests  that  the  more  complex  data  types  might  have  been  packaged 
but  not  hidden.  However,  programmer  3  made  more  references  to  components  of 
unpackaged  data. 

Table  4  summarizes  the  component  accesses  by  package  for  selected  packages. 
Note  that  package  3  has  217  of  the  packaged  component  accesses.  This  Is  not  surprising 
considering  that  the  package  contains  global  data  and  types.  The  majority  of  the 
remaining  packaged  component  accesses  were  to  package  7  which  provides  some  types 
shared  by  several  related  units.  If  the  data  In  these  two  packages  were  hidden,  the 
number  of  packaged  component  accesses  and  the  effect  of  changes  to  the  packages 
would  be  greatly  diminished.  However,  changes  to  the  representation  at  this  time  would 
affect  many  other  units. 

Table  3;  Component  Accesses  by  Programmer 


Metric 

1 

Programmer 

L_2 _ L_3 _ 14 _ 

Total 

Text  Lines 

706 

1904 

1648 

117 

4375 

Component  Accesses 

all  data 

159 

140 

0 

470 

only  packaged  data 

120 

61 

0 

305 

excluding  packaged  data 

30 

47 

70 

0 

165 

Accesses  per  Text  Line 

all  data 

0.23 

0.09 

0.08 

0.00 

0.11 

only  packaged  data 

0.17 

0.06 

0.0! 

0.00 

0.07 

excluding  packaged  data 

0.06 

0.02 

0.0.5 

0.00 

0.03 

'.‘-".•I 


Tabic  Comi)oncnt  Accesses  by  Package 


Package 

#  of  Units 

#  of  Accesses 

3 

13 

217 

2 

1 

0 

8 

2 

14 

7 

6 

46 

5 

1 

19 

The  values  In  Table  3  Indicate  that  the  first  programmer's  code  should  be  relatively 
difficult  to  change  since  about  one  of  every  five  lines  contained  a  component  access.  We 
selected  one  of  this  programmer’s  modules  and  made  the  trivial  modification  discussed 
In  Section  4.2.  To  make  this  change  In  the  representation,  eleven  program  changes 
[Dunsmore  and  Gannon  77]  were  required  In  the  module  we  selected.  In  addition,  ten 
program  changes  were  needed  In  five  other  modules  which  encompassed  two  of  the  four 
major  subsystems  In  the  program.  The  record  type  containing  these  components  could 
have  been  encapsulated  In  a  package  definition.  Then,  the  same  change  In  the  represen¬ 
tation  would  require  a  change  In  the  private  part  of  the  package  specifications  and  a 
total  of  four  program  changes  In  two  functions  of  the  package  body.  No  other  modules 
would  be  affected. 

8.  Conclusions 

The  case  study  demonstrates  what  might  happen  when  programmers  who  are 
experienced  In  an  application  area  but  lack  training  In  modern  software  development 
practices  begin  to  use  Ada.  Despite  training  efforts  that  are  similar  to  those  that  are 
likely  to  be  used  In  a  typical  Industrial  setting,  only  traditional  modules  like  device 
drivers  and  mathematical  libraries  were  defined.  Encapsulated  types  were  declared  only 
by  programmers  with  the  widest  exposure  to  different  languages,  but  even  the  program¬ 
mers’  prior  success  In  working  with  these  languages  does  not  guarantee  success  with 
Ada.  A  good  background  In  the  software  engineering  practices  which  Ada  supports  Is 
probably  necessary  to  learn  to  use  the  full  capabilities  of  tlie  features  of  the  language  — 
simply  teaching  professional  programmers  Ada  Is  not  enough. 

Had  the  package  metrics  been  applied  during  the  case  study,  they  might  have 
helped  the  programmers  better  understand  how  to  use  packages.  Package  visibility  Is  a 
rather  crude  metric  that  can  be  used  during  design  to  check  that  the  designer’s 
approach  to  a  system  Is  not  simply  to  make  all  packages  visible  to  all  program  units. 
Lowering  the  visibility  will  probably  decrease  the  scope  of  any  changes  made  to  the 
package. 

However,  even  If  package  visibility  Is  restricted,  packages  may  still  export  type 
definitions  that  permit  programmers  to  access  the  components  of  composite  objects. 
Program  units  that  directly  access  components  of  objects  are  likely  to  be  difficult  to 
change. 
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Metrics  which  track  the  use  of  packages  during  system  clevelopmeut  treat  the 
symptoms  and  not  the  problem;  however,  we  expect  many  early  developments  will  have 
these  symptoms.  These  metrics  and  those  described  In  [Hammons  and  Dobbs  85]  may 
help  In  the  transition  to  using  Ada  effectively. 
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package  P  Is 
procedure  X; 
end  P; 

separate  (P) 
procedure  X  Is 
begin 

•••* 

end  X; 

with  P; 
procedure  A  Is 
procedure  B  Is  separate; 
procedure  D  Is  separate; 
begin 
•••> 

end  A; 


A^ 


separate(A) 
procedure  B  Is 
procedure  C  Is  separate; 
begin 


end  B; 

separate  (A.B) 
procedure  C  Is 
begin 

•••» 

end  C; 


separate  (A) 
procedure  D  Is 
begin 


end  D; 


FIGURE  1:  Global  Visibility  of  Package  P 


package  P  Is 
procedure  X; 
end  P; 


separate  (P) 
procedure  X  Is 
begin 

•••» 

end  X; 

procedure  A  Is 
procedure  B  Is  separate; 
procedure  D  Is  separate; 
begin 

•••« 

end  A; 


P 


( 

X 


with  P; 
separate(A) 
procedure  B  Is 
procedure  C  Is  separate; 
begin 


P.X; 


end  B; 


separate  (A.B) 
procedure  C  Is 
begin 

•••» 

end  C; 


with  P; 
separate  (A) 
procedure  D  Is 
begin 


P.X; 


end  D; 
A 

B  D 
\ 

C 


FIGURE  2;  Limited  Visibility  of  Package  P 
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